[PATCH] cmake/QtBuildInternalsExtra.cmake.in: Patch out embedded build path.
The original build path should not be needed in the shipped package,
and causes reproducibility issues when built in different paths.
https://reproducible-builds.org/docs/build-path/
Gbp-Pq: Name build_path_embedded_qtbuildinternalsextra_cmake.patch
Add SH description
Bug-Debian: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=
1043225
Reviewed-by: Lisandro Damián Nicanor Pérez Meyer <lisandro@debian.org>
Upstream processes archs from time to time and tends to disable those that
they do not know wether they are working or not.
SH is working on Debian, so as an intermediate measure re enable it here.
Gbp-Pq: Name Add-SH-detection.patch
[PATCH] Revert "QProcessEnvironment: simplify locking"
This reverts commit
c5d6b263c204cb09db2be36826e19acb03dc24fb.
The commit being reverted assumes the mutex is only protecting 'nameMap'
and nothing else is mutable, which is false. The mutex is not only
protecting 'nameMap' but also protecting the containing value objects,
since even though the value object is accessed read-only, its
implementation mutates its internal states for 2-way conversion between
ByteArray and QString.
Commit
85e61297f7b02297641826332dbdbc845a88c34b ("restore
QProcessEnvironment shared data thread safety on unix") said that
implicit sharing together with 'mutable' is a time bomb and the bomb is
triggered by the reverted commit.
Fixes: QTBUG-142938
Pick-to: 6.8
Change-Id: I9e3234f0eb2c691eccf753a11f63fae9944bd503
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@gmx.de>
(cherry picked from commit
080d61c020678b75ed9d5acb062ec82ba8fc402f)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
(cherry picked from commit
62917e4b518ecaa9dc34337e30f12eaeb41e790e)
Gbp-Pq: Name upstream_Revert-QProcessEnvironment-simplify-locking.patch
[PATCH] QFileSystemEngine: handle copy_file_range() returning ENOSYS error
This shouldn't have happened, because minimum-linux_p.h would have
declared our need for a Linux kernel 4.5 or higher. I think the issue is
not the kernel, but a container wrapping the Qt application and
filtering system calls for security. If this container hasn't been
updated to know about the system call, it may cause an ENOSYS error.
Because we now handle the condition, this commit removes the 4.5 minimum
Linux version requirement from minimum-linux_p.h.
[ChangeLog][QtCore][QFile] Added a workaround to a compatibility issue
of the copy() implementation in some containerized Linux environments,
which could cause the file copy to fail with a "Function not
implemented" error. This is believed to be a bug in the container
runtime, not Qt, in that the container wrongly filtered the
copy_file_range(2) system call that the Linux kernel supports.
Fixes: QTBUG-144142
Change-Id: Iedbf805486ad79e7127dfffd22043889359563fd
Reviewed-by: Ivan Solovev <ivan.solovev@qt.io>
Reviewed-by: Ahmad Samir <a.samirh78@gmail.com>
(cherry picked from commit
b1b45ca4441db9e880e3a7fc7f4e8aa3af870eb6)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
(cherry picked from commit
7b8591ac572079e59f856fb0ac7f4e3312f6dd43)
Gbp-Pq: Name upstream_QFileSystemEngine-handle-copy_file_range-returning-E.patch
[PATCH] rhi: vulkan: Fix unintentional SDR format selection
I needed to read back the swapchain image for my Vulkan RHI-enabled
QtQuick application, but it complained that
VK_FORMAT_A2R10G10B10_UNORM_PACK32 wasn't able to be read back - why?
My initial naive solution is to simply add it to the
swapchainReadbackTextureFormat function - but that wouldn't work as
there is no BGR10A2 RHI texture format and applications would unkowingly
end up with swapped channels. The actual problem came down to how we
were selecting swapchain image formats.
The first thing I changed was the hdrFormatMatchesVkSurfaceFormat
function, because that checked two formats for HDR10:
VK_FORMAT_A2B10G10R10_UNORM_PACK32 and
VK_FORMAT_A2R10G10B10_UNORM_PACK32. Checking the online Vulkan hardware
database, the BGR variant is more well-supported. Picking the RGB
variant is inevitably going to lead into the problem described before -
and should be added back when & if a new RHI texture format is
introduced.
The next thing I changed was the swapchain format selection logic,
specifically the choice for a non-sRGB SDR format. Judging by the
comments in this function and other RHIs like DX12 we *want* the default
color format of VK_FORMAT_B8G8R8A8_UNORM unless otherwise requested.
That isn't what was happening though, on my specific hardware it was
choosing VK_FORMAT_A2R10G10B10_UNORM_PACK32 - why?
It comes down to the isSrgbFormat check in the loop. Again, for the
non-SRGB SDR case the "srgbRequested" variable is always false. And when
a non-SRGB format (like the aforementioned problematic VkFormat) is
checked isSrgbFormat will return false, but I don't think that's what is
intended here. We want that for the sRGB case, but for non-SRGB SDR the
default color format is fine and that lines up with other RHIs
(see QD3D12SwapChain::chooseFormats for an example.) I checked this
inside the loop so the passthrough code is still ran on Wayland, but I
think the new logic is still sensible.
I tested this against the five usual cases I could think of and now the
format selection seems sensible:
* non-sRGB SDR chose VK_FORMAT_B8G8R8A8_UNORM
* sRGB SDR chose VK_FORMAT_R8G8B8A8_SRGB
* extended sRGB Linear chose VK_FORMAT_R16G16B16A16_SFLOAT
* HDR10 chose VK_FORMAT_A2B10G10R10_UNORM_PACK32
* Display P3 chose VK_FORMAT_R16G16B16A16_SFLOAT
Change-Id: Ie79e9fcaa1130311958b485af9b73c59d5d9a335
Reviewed-by: Laszlo Agocs <laszlo.agocs@qt.io>
(cherry picked from commit
2dd1aa3678d541aef15b564b4013728ed5b0387b)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
(cherry picked from commit
f4c5e54a8703944ec7ea005ad4de3072b86fd61f)
Gbp-Pq: Name upstream_hdr_vulkan.diff
[PATCH] Update sources to support OpenSSL 4
OpenSSL 4 now uses const in logical cases across its X.509 API; this
patch updates Qt's TLS backend to compile against both 3.x and 4.x.
To do this QT_OPENSSL4_CONST macro (expands to `const` on OpenSSL >= 4,
empty otherwise) is introduced for functions which changed in OpenSSL 4.
There were pre-existing functions that were already const in OpenSSL 3
but were declared without const in Qt's wrapper layer - they have now
been fixed with plain const.
ASN1_STRING was made opaque in OpenSSL 4, so replace direct access with
use of accessor functions through the wrappers.
tst_qsslcertificate: add expected output for OpenSSL 4's slightly
different extension formatting.
tst_qsslsocket::ecdhServer: lock to TLS 1.2 as OpenSSL 4 no longer
exports DH/ECDH parameters for TLS 1.3 sessions.
Fixes: QTBUG-145221
Pick-to: 6.8
Change-Id: Ic3f7d3cf00dbcb5b4cd1a299d3608a7c694a3454
Reviewed-by: Mate Barany <mate.barany@qt.io>
Reviewed-by: Jonas Kvinge <jonas@jkvinge.net>
(cherry picked from commit
e806630e694d89f567cffa9c982d1f471089ecd8)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
Gbp-Pq: Name upstream_openssl4.patch
qt6-base (6.10.2+dfsg-15) unstable; urgency=medium
[ Patrick Franz ]
* Backport patch to support OpenSSL 4 (Closes: #
1138359).
[dgit import unpatched qt6-base 6.10.2+dfsg-15]
projects / qt6-base.git / log